Learning Domain Driven Design - 6. Tackling Complex Business Logic

前回はシンプルなビジネスロジックに対するパターン

Transaction Script

ActiveRecord

今回は複雑なビジネスロジックに対するDDDパターンについて

まとめ

ドメインモデルパターンの紹介

より複雑なビジネスロジックに適している

Value Object, Aggregates, Domain Service から構成される

歴史を簡単に紹介

Domain Model

複雑なビジネスロジックを管理するために利用する設計パターン

振る舞いとデータをカプセル化するオブジェクトモデル

ValueObject, Aggregation, Domain Service を利用する

複雑なビジネスロジック (= ActiveRecord を使用して実装するのが難しい) の例

e.g. ヘルプデスクシステムの設計

顧客がチケットを作成

顧客とエージェントがメッセージを追加できる

チケットには優先度に基づいた時間制限がある

制限内に応答がない場合、エスカレートされ、再度超えると別のエージェントに割り当てられる

顧客が 7日以内に反応しない場合自動で閉じる

マネージャー、顧客のみチケットを閉じられる

顧客は7日以内に閉じられたものなら再度開ける

Domain Model は、データベース呼び出しやシステムの外部コンポーネントなど技術的な問題は取り扱わない

モデルのオブジェクトはプレーンなオブジェクトであり、インフラのコンポーネントやフレームワークに直接依存はしない

技術的な問題よりもビジネスロジックを優先することで、ユビキタス言語との整合性を保ちやすくなる

つまり、コードがユビキタス言語を話すことが可能になる

構成要素 Value Object, Aggregates, Domain Service それぞれについて説明していく

Value Object

その値の組み合わせで識別されるオブジェクト。明示的なIDを持つ必要がない

e.g. Color Object

code:java

class Color

{

int _red;

int _green;

int _blue;

}

Primitive Obsession: プリミティブな値のみのフィールドでドメインを表現するコードスメル

正確な値が入ることを保証するため、全ての入力を検証する必要があるが、検証ロジックが色々な場所に重複したり、値を利用する前に検証ロジックの呼び出しを強制するのが難しい

code:java

class Person

{

private int _id;

private string _firstName;

private string _lastName;

private string _countryCode;

public Person(...) {...}

}

code:go

type Sample struct {

}

func New(a string) (*Sample, error) {

s := &Sample{

A: a,

}

if err := validate.Struct(s); err != nil {

return nil, err

}

return s, nil

}

// ng

s1 := Sample{A: "hoge"}

var s2 Sample

s3 := new(Sample)

// ok

s4, _ := New("fuga")

Value Object はそれに対する解決策として有用

明確さが向上し、Value Object が検証ロジックをカプセル化しているため代入前に検証する必要がなくなる

値の操作に関するビジネスロジックも検証し、テストも容易になる

また、この Value Object が表現する概念はユビキタス言語と一致する

code:java

class Person {

private PersonId _id;

private Name _name;

private CountryCode _country;

public Person(...) { ... }

}

immutable である必要がある

意図しない副作用を防ぐ、スレッドセーフにするため

また、等価性 equality も正しく実装する必要がある

.NET や Java など多くの言語では、文字列型が Value Object として実装されている

Entities

Value Object と異なり、一意に識別できる ID をもつオブジェクト

mutable

プロパティに Value Object を利用できる

Aggregates

Entity 一つ以上からなるもので、整合性を保つもの

整合性を保つため、他の Aggregate と明確な境界を引く

Aggregate の外部からは

状態を読むことのみが許される

変更は公開 i/f の実行 (Command とも呼ばれる) でのみ可能

code:java

public class Ticket

{

...

public void Execute(AddMessage cmd)

{

var message = new Message(cmd.from, cmd.body);

_messages.Append(message);

}

...

}

Aggregate は並行に実行されても整合性を担保する必要がある

トランザクション境界としても機能する

-> 一つ一つの Aggregate を個々のトランザクションとしてコミットできる

トランザクション境界でまとめた例

https://gyazo.com/c6375e5426536b3090829987e821cfe6

https://gyazo.com/bf84eb0b119e3437445ab8fcbc453d1c

この図における Ticket が Aggregate Root と呼ばれるものになる

Aggregate の中で一つの Entity が i/f を公開する形になる

code:java

public class Ticket

{

...

List<Message> _messages;

...

public void Execute(EvaluateAutomaticActions cmd)

{

if (this.IsEscalated && this.RemainingTimePercentage < 0.5 &&

GetUnreadMessagesCount(for: AssignedAgent) > 0)

{

_agent = AssignNewAgent();

}

}

public int GetUnreadMessagesCount(UserId id)

{

return _messages.Where(x => x.To == id && !x.WasRead).Count();

}

...

}

Value Object と同様、Aggregate の名前 (public i/f, field) はユビキタス言語と一致しているべき

Domain Expert とコミュニケーションしやすくなる

Domain Events

Aggregate Root の public i/f 以外に、Aggregate とコミュニケーションする方法の一つ

https://gyazo.com/fa7199466392ea9b469b82f4a4ce91d2

e.g.

Ticket assigned

Ticket escalated

Message received

transaction 境界を分けたときに整合性を保つのが大変。domain event を使うとインフラ周りの複雑度が増して運用が大変になってくる

Domain Services

システムの拡大に伴い、ビジネスロジックが特定の Aggregate や Value Object に明確に分類されず、複数の Aggregate に関連しているように見えるケースが出てくるはず。この場合にそのロジックを Domain service として実装するのを提案する

Stateless

複数のシステムコンポーネントへの呼び出しを調整する

これは microservice, service oriented architecture, その他のサービスとは無関係で、単なるビジネスロジックをホストする stateless なオブジェクトにすぎないので注意

code:java

public class ResponseTimeFrameCalculationService

{

...

public ResponseTimeframe CalculateAgentResponseDeadline(UserId agentId,

Priority priority, bool escalated, DateTime startTime)

{

var policy = _departmentRepository.GetDepartmentPolicy(agentId);

var maxProcTime = policy.GetMaxResponseTimeFor(priority);

if (escalated) {

maxProcTime = maxProcTime * policy.EscalationFactor;

}

var shifts = _departmentRepository.GetUpcomingShifts(agentId,

startTime, startTime.Add(policy.MaxAgentResponseTime));

return CalculateTargetTime(maxProcTime, shifts);

}

}

複雑さを管理する

ここまで紹介してきた Aggregate, Value Object, Domain Service はドメインの複雑さに対処するための手段

オブジェクトの自由度を下げ、immutable にすることで複雑さを減らすことができる

まとめ

ビジネスロジックの複雑さを、境界を区切ってカプセル化することで対処する

Value Objects

その値でのみ一意に識別できる(IDをもたない)ビジネスドメイン

Aggregates

トランザクション境界で区切られ、強力な整合性を持つ

public i/f でのみ更新できる (= command)

domain event を使うことでも他の境界ともやりとりできる

Domain Services

stateless で複数の value object, aggregate を管理するもの

次の章では、"時間" という次元を取り入れたより高度な方法を学ぶ

event sourcing